NASA/TM— 20 12-217819 



Space Telecommunications Radio System (STRS) 
Architecture 

Tutorial Part 1 — Overview 


Louis M. Handler and Janette C. Briones 
Glenn Research Center, Cleveland, Ohio 

Dale J. Mortensen 

ASRC Aerospace Corporation, Cleveland, Ohio 

Richard C. Reinhart 

Glenn Research Center, Cleveland, Ohio 


December 2012 


NASA STI Program ... in Profile 
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The NASA STI Program operates under the auspices 
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NASA’s STI. The NASA STI program provides access 
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limitations on manuscript length and extent of 
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• TECHNICAL MEMORANDUM. Scientific 
and technical findings that are preliminary or 
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reports, working papers, and bibliographies that 
contain minimal annotation. Does not contain 
extensive analysis. 

• CONTRACTOR REPORT Scientific and 
technical findings by NASA-sponsored 
contractors and grantees. 
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papers from scientific and technical 
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meetings sponsored or cosponsored by NASA. 
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NASA programs, projects, and missions, often 
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and publishing research results. 
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Information Desk at 443-757-5803 

• Phone the NASA STI Information Desk at 
443-757-5802 

• Write to: 

STI Information Desk 

NASA Center for AeroSpace Information 

7115 Standard Drive 

Hanover, MD 21076-1320 


NASA/TM— 20 12-217819 



Space Telecommunications Radio System (STRS) 
Architecture 

Tutorial Part 1 — Overview 


Louis M. Handler and Janette C. Briones 
Glenn Research Center, Cleveland, Ohio 

Dale J. Mortensen 

ASRC Aerospace Corporation, Cleveland, Ohio 

Richard C. Reinhart 

Glenn Research Center, Cleveland, Ohio 


National Aeronautics and 
Space Administration 


Glenn Research Center 
Cleveland, Ohio 44135 


December 2012 


Trade names and trademarks are used in this report for identification 
only. Their usage does not constitute an official endorsement, 
either expressed or implied, by the National Aeronautics and 
Space Administration. 


Level of Review. This material has been technically reviewed by technical management. 


Available from 


NASA Center for Aerospace Information 
7115 Standard Drive 
Hanover, MD 21076-1320 


National Technical Information Service 
5301 Shawnee Road 
Alexandria, VA22312 


Available electronically at http://www.sti.nasa.gov 


Space Telecommunications Radio System (STRS) Architecture 

Tutorial Part 1 — Overview 

Louis M. Handler and Janette C. Briones 
National Aeronautics and Space Administration 
Glenn Research Center 
Cleveland, Ohio 44135 

Dale J. Mortensen 
ASRC Aerospace Corporation 
Cleveland, Ohio 44135 

Richard C. Reinhart 

National Aeronautics and Space Administration 
Glenn Research Center 
Cleveland, Ohio 44135 

Abstract 

Space Telecommunications Radio System (STRS) Architecture Standard provides a NASA standard 
for software-defined radio. STRS is being demonstrated in the Space Communications and Navigation 
(SCaN) Testbed formerly known as Communications, Navigation and Networking Configurable Testbed 
(CoNNeCT). Ground station radios communicating the SCaN testbed are also being written to comply 
with the STRS architecture. The STRS Architecture Tutorial Overview presents a general introduction to 
the STRS architecture standard developed at the NASA Glenn Research Center (GRC), addresses 
frequently asked questions, and clarifies methods of implementing the standard. The STRS architecture 
should be used as a base for many of NASA’s future telecommunications technologies. The presentation 
will provide a basic understanding of STRS. 


NASA/TM— 2012-217819 


1 




National Aeronautics and Space Administration 



Space Telecommunications 
Radio System (STRS) 
Architecture 


Tutorial Part 1 - Overview 


Glenn Research Center 
November 201 1 


www.nasa.gov i 


NASA/TM— 2012-217819 


3 


National Aeronautics and Space Administration 


STRS Architecture 

• STRS Background 

• STRS Hardware & Software Structure 

• STRS Infrastructure APIs 

• STRS Application APIs 

• STRS Configuration Files 

• STRS Reference Documents 
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STRS Background 
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STRS Goals and Objectives 

• Applicable to space and ground missions of varying 
complexity. 

• Decrease the development time and cost of deployed 
capabilities. 

• Increase the reliability of deployed radios. 

• Accommodate advances in technology with minimal 
rework. 

• Adaptable to evolving requirements. 

• Enable interoperability with existing radio assets. 

• Leverage existing or developing standards, resources, 
and experience. 

• Maintain vendor independence. 

• Enable waveform portability between compliant platforms. 

• Enable cognitive radio concepts. 
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STRS Solution: Software-Defined Radio (SDR) 

• SDRs are commonplace in commercial and military 
industries. 

- accommodates advances in technology 

- enables cognitive radio concepts 

• SDRs allow encapsulation of functionality. 

- allows multiple vendors to work on different parts of the 
radio at once 

- allows updates to one part not to affect the other parts 
of the radio 

- allows portability 

• Software design and implementation processes may be 
leveraged to lower risk and increase reliability 
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STRS Background 


@r 


• SDRs present unique challenges in space. 

- Radiation environment 

- Temperature extremes 

- Autonomous operation 

- Size, weight, and power (SWaP) limitations 

- Timescale of deployments 

- Lengthy development cycles 

• JTRS/SCA and OMG/SWRADIO were investigated 

- including CORBA was too cumbersome due to SWaP 

- including an XML parser was too cumbersome due to SWaP 

- SCA’s XML configuration files were too complex for our needs 

- Used Platform Independent Model (PIM) as a starting point for 
STRS API design 

• Decided to allow a C language interface to minimize SWaP 
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STRS Hardware and 
Software Structure 
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SDR Signal Processing Hardware 




General Purpose 
Processor (GPP) 
typically contains and 
executes the Managing 
Software enabling 
Software Defined Radio 
functionality 


Specialized Hardware 
contains and executes 
Application Software 
(i.e. firmware) enabling 
higher rate processing 
within the Software 
Defined Radio (e.g. 

FPGA) 
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Waveform Application Decomposition 



Waveform Applications & High Level Services 


Operating Environment 


Waveform Component 


HW 


Waveform Component 


Low rate waveform 
application components 
allocated to processor based 
signal processor. High level 
services used to control and 
monitor application software 

•Operating Environment (OE) 
provides access to processor 
and specialized hardware for 
waveform processing 

•High rate waveform 
application components 
allocated to specialized 
processing hardware 

Waveform decomposition driven 
by designers, not architecture 
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STRS Open Architecture 

Waveform Application API and Hardware Abstraction 



Waveform Applications & High Level Services 


API 


Operating Environment 


Waveform Component 


HW 



Waveform Component 


•Waveform designers access 
specified API to access processor 
and implements radio controls in 
the GPP 


• APIs specified by architecture 
separate the waveform from the 
Operating Environment for 
waveform portability 


•Operating Environment provides 
published interfaces (API) 
services and hardware 
abstraction control to waveform 


• Hardware Abstraction Layer 
(HAL) also provides wrapper to 
help port HDL software among 
platforms 
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STRS Architecture 



Layer cake model 

Waveform applications and high level services are insulated from OE by 
APIs 


STRS APIs abstract 
away many platform 
differences 
POSIX used to 
reduce API 
development - 
OE 

Hardware Abstraction 
Layer (HAL) 


Waveform Applications and High Level Services 


^ POSIX API Subset 


OS 


BSP 


GPM 


STRS API 


STRS Infrastructure 


Network Stack 


i 


-> HAL API 


Drivers 


Specialized HW 
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STRS Architecture Conformance ® 


Conformant to STRS 
Architecture Standard 
requirements for 
applications 


□ Conformant to STRS 
Architecture Standard 
(STRS and WFAPIs) 


Compliant to POSIX PSE51 
or Subset with Waiver 


Documented HAL and HID 
as required by STRS 
Architecture Specification 


Waveform Applications and High Level Services 



HAL API 


BSP 

Drivers 

GPM 

Specialized HW 
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Layer Cake Transition to UML 
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STRS Layered Structure 



Flight Computer External Port Payload Antenna FPGA Master Clock Other Specialed HVV 
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STRS Infrastructure APIs 

• STRS Infrastructure APIs are used: 

- Waveform calls methods in Infrastructure. 

- Infrastructure calls appropriate method in another Waveform, 
Device, or Infrastructure. 

• Purpose: 

- Methods separate a request from the accomplishment of that 
request. 

- Methods are ‘extern “C”’ so that they can be called from 
either C or C++. 

- Methods insulate waveforms from having to know how 
another waveform, device or the infrastructure is 
implemented. 
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STRS Infrastructure APIs 



Queue Control 

• STRS_QueueCreate 

• STRS_QueueDelete 

• STRS_Read 

• STRS_Register 

• STRS_Log 

• STRS_Write 

• STRS_Un register 
Device Control 

• STRS_DeviceClose 

• STRS_DeviceFlush 

• STRS_DeviceLoad 

• STRS_DeviceOpen 

• STRS_DeviceReset 

• STRS_DeviceStart 

• STRS_DeviceStop 

• STRS_DeviceUnload 

• STRS_SetlSR 
Testing 

• STRS_RunTest 

• STRS_GroundTest 
Attribute 

• STRS_Configure 

• STRS_Query 
Process Errors 

• STRS_GetErrorQueue 

• STRS IsOK 


Control 

• STRSJnitialize 

• STRS_ReleaseObject 

• STRS_Start 

• STRS_Stop 
Application 

• STRS_HandleRequest 

• STRS_lnstantiateApp 

• STRS_AbortApp 
Time 

• STRS_GetNanoseconds 

• STRS_GetSeconds 

• STRS_GetTimeWarp 

• STRS_GetTime 

• STRS_SetTime 

• STRS_Synch 
File (Named Area) 

• STRS_FileClose 

• STRS_FileGetFreeSpace 

• STRS_FileGetSize 

• STRS_FileOpen 

• STRS_FileRemove 

• STRS FileRename 


• The STRS Software 
Architecture presents a 
consistent set of APIs to 
allow waveform 
applications, services, 
and communication 
equipment to interoperate 
in meeting a waveform 
specification 

• These APIs are used in 
general or to control one 
waveform from another 

• The list to the left is the 
minimum list of APIs that 
the STRS platform 
infrastructure must 
implement 
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STRS OE Compliance 



STRS 





Document 



Implements STRS_API 
Uses STRS Application API 
Uses HAL API 

Supports WF 

Supports Device 
Supports File 
Supports Queue 

Supports health/fault management 
Parses configuration files 

BIT 

WDT 

HAL, 

HID, etc. 
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STRS Waveform APIs 
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STRS Waveform Application Compliance 



• A waveform is an STRS 
Application and must implement 
the APIs shown in the diagram 

•An STRS Application has 
OMG similarity; but STRS 
requires everything, except 
source and sink (STRS replaces 
OMG ports with source/sinks) 

• The diagram shows how a 
Device fits in the infrastructure 

o Device is internal, must have 
the shown functionality 
o Device is an abstraction 
(proxy) that uses the HAL to 
get to the hardware 
o No standard for the HAL API. 
Standard is at Device level 
(provider) 



jdata or command transfer 


X 1 

7 

Specia 

lized H 

H-sk 

SSP 

ardware 

/ 
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POSIX Compliance/Conformance 



POSIX Conformant OS: 



POSIX Compliant OS: 



An STRS operating environment can either use an OS that conforms with 1003.13 PSE51 or 
provide a POSIX abstraction layer that provides missing PSE51 interfaces. For constrained 
resource platforms, the POSIX requirement is based on waveform requirements so that the 
waveforms are upward compatible (require POSIX methods). 
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STRS 


STRS Waveform Compliance 
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STRS Configuration Files 
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Configuration Files 



• Require schema and 
XML as part of the 
architecture 

• The required XML 
should be 
transformed to a 
compact format 

• The approach for the 
transformation is not 
mandated as part of 
the architecture 

• STRS Reference 
Implementation uses 
XSL/XSLT to 
transform XML to an 
S-expression as 
compact form 
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STRS Reference Documents 
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STRS Reference Documents 

• Space Telecommunications Radio System (STRS) 
Architecture Standard Release 1.02.1, December 
2010, NASA TM 2010-216809 

httD://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/201 10002806 201 1001718.pdf 

• Space Telecommunications Radio System (STRS) 
Architecture Goals/Objectives and Level 1 
Requirements Document, June 2007, NASA TM 

2007- 215042. 

httD://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20080008862 2008008550.pdf 

• Space Telecommunications Radio System (STRS) 
Definitions and Acronyms, May 2008, NASA TM 

2008- 215445. 

http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/200900Q5977 2009004914.pdf 
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Backup Slides 
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Waveform State Diagram 
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Simplified Diagram 
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STRS Reference Implementation Development Process 


Use Case Identifier: Example Use Case 

Description: A Description of the use case goes here. 

External Actors: External actor(s) involved with this 
specific use-case. 

Related Use Cases: Use cases that related to this use 
case by interaction or similarity. 

Precondition: Any precondition that must exist before 
this use case can occur. Usually the initial RADIO 
state and WAVEFORM state is listed 
Triggering event: Event that trigge^ Not 

all use cases have triggering events^ 


ssary to 
"al flow. 



Main Flow: 

1 .This will be an ordered 1: 
perform interaction. T! 
Alternate flows <^1 
2. Step 2 
3. Step 3 
4. Step 4 v 


Resmiii^r's^cn^z If completion of use case results in 
an events^^nsted here. Usually the resulting RADIO 
state and WAVEFORM state is listed. 

Post condition: Describe the result of the use case 
interaction. (This is the post condition from the 
nominal flow) 

Alternatives: 

1 a) This is where alternate flows are identified. The 
alternative will be identified by the number of the main 
flow where the branch occurs followed by a letter a-z. 

3 a) This is an example of an alternative flow for step 3. 
3b) This is the second step in the alternative flow for 
step 3. 

7a-8a) This is an alternative flow for a range of steps 
from the main flow. 


Comments: Comments on use case. 



Refines Requirements 






VieVJ 




Class Diagram 


'Uves D 


ynartiic Vy 


e\v 


Refines Requirements 




Sequence Diagram 


Use Case 
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Use Case Overview 




A set of use cases were developed which is a set of scenarios that capture the 
different ways that external users interact with the STRS radio. 
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Class Example 




Application Manager 

• The Application Manager is 
responsible for the passing of 
messages or invoking commands 
in other application objects such 
as devices, waveforms, or 
services actively running on the 
STRS radio. 

• It is responsible for creating or 
aborting application objects, 
waveforms, or services. 

• It is also responsible for parsing 
the Configuration Files and setting 
corresponding values in the 
appropriate classes. 


Application Manager 


-appTable 

-configTable 


+parseConfigurationFile() 

+instance() 


Above is an example of the 
UML representation of a Class 


Name - Name that identifies the 
class and describes the functionality 
Attributes - Variables containing the 
applicable data 

Methods - Functions that are called to 
implement some operation 
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STRS Open Architecture Hardware 

Representation 




Control 

Clock 

System Bus 



Control 
Ground T est 
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SDR/STRS Hardware Functional 

Diagram 
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SDR/STRS Hardware Functional 

Diagram 



RF Module -handles the RF functionality to tran sin its/receive 
the digital signal. Its associated components include RF 
switches, diplexer, filters, LNAs and power amplifiers. 3E 
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STRS Hardware Functional Diagram 



APIs separate waveform from operating 
environment - enabling waveform portability. 


I 


neral Processing Module (GPM) 


Ground Test 
Interface 


Host/TT&C 

Interface 


Work Area Memory 


Persistent Memory 


Software/Firmware Abstraction: Layers 
define interfaces between components, 
separating SW/FW from HW. 












Spacecraft 


Data 


Data 


Data 


Buffer/ 



Interface 


Storage 


Formatting 


General Purpose Processor 


Waveform / 
Application 
, API 

Operating 

Environment 


HAL 


Low Speed 
Signal 
Processing 


Radio 

Configu, ation 
& System 
Control 


Test & 
Status 


System 

Control 


Clock 

Distribution 


High Speed 
Digital Signal 
Processing 


Signal Processing Module (SPM) 


Managing Software runs on GPM 


F1AL API is published so that 
specialized HW developed by 
multiple vendors can be 
integrated with another vendor’s 
STRS infrastructure. 


Variable 

Gain/ 

Frequency 

UIDI 


Clock 

Interface 


Analog to 
Digital 


Test & Status on 
each module 






Test & 
Status 


Antenna 

Control 

Interface 


Digital to 
Analog 


Receive RF 


Transmit RF 


Antenna 

Interface 


RF Module (RFM) 


i 


Module Interfaces abstract and define the module functionality for data flow to waveform components. Enables 
multiple vendors to provide different modules or add modules to existing radios. Electrical interfaces, connector 
requirements, and physical requirements are specified/published by the platform provider. 
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The End 


www.nasa.gov 37 


NASA/TM— 2012-217819 


39 


REPORT DOCUMENTATION PAGE 


Form Approved 
OMB No. 0704-0188 


The public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the 
data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this 
burden, to Department of Defense, Washington Headquarters Services, Directorate for Information Operations and Reports (0704-0188), 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302. 
Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to any penalty for failing to comply with a collection of information if it does not display a currently valid OMB 
control number. 

PLEASE DO NOT RETURN YOUR FORM TO THE ABOVE ADDRESS. 


1. REPORT DATE (DD-MM-YYYY) 
01 - 12-2012 


2. REPORT TYPE 

Technical Memorandum 


4. TITLE AND SUBTITLE 

Space Telecommunications Radio System (STRS) Architecture 

Tutorial Part 1— Overview 


3. DATES COVERED (From - To) 


5a. CONTRACT NUMBER 


5b. GRANT NUMBER 


6. AUTHOR(S) 

Handler, Louis, M.; Briones, Janette, C.; Mortensen, Dale, J.; Reinhart, Richard, C. 


5c. PROGRAM ELEMENT NUMBER 


5d. PROJECT NUMBER 


5e. TASK NUMBER 


7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 

National Aeronautics and Space Administration 
John H. Glenn Research Center at Lewis Field 
Cleveland, Ohio 44135-3191 


5f. WORK UNIT NUMBER 

WBS 439432.04.07.01 


8. PERFORMING ORGANIZATION 
REPORT NUMBER 

E-18561 


9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 

National Aeronautics and Space Administration 
Washington, DC 20546-0001 


12. DISTRIBUTION/AVAILABILITY STATEMENT 

Unclassified-Unlimited 

Subject Categories: 17 and 61 

Available electronically at http://www.sti.nasa.gov 

This publication is available from the NASA Center for AeroSpace Information, 443-757-5802 


10. SPONSORING/MONITOR'S 
ACRONYM(S) 

NASA 


11. SPONSORING/MONITORING 
REPORT NUMBER 

NAS A/TM-20 12-217819 



14. ABSTRACT 

Space Telecommunications Radio System (STRS) Architecture Standard provides a NASA standard for software-defined radio. STRS is 
being demonstrated in the Space Communications and Navigation (SCaN) Testbed formerly known as Communications, Navigation and 
Networking Configurable Testbed (CoNNeCT). Ground station radios communicating the SCaN testbed are also being written to comply 
with the STRS architecture. The STRS Architecture Tutorial Overview presents a general introduction to the STRS architecture standard 
developed at the NASA Glenn Research Center (GRC), addresses frequently asked questions, and clarifies methods of implementing the 
standard. The STRS architecture should be used as a base for many of NASA’s future telecommunications technologies. The presentation 
will provide a basic understanding of STRS. 


15. SUBJECT TERMS 

User manuals (computer programming); Architecture (computers); Telecommunications 


16. SECURITY CLASSIFICATION OF: 


a. REPORT 

u 


b. ABSTRACT 

u 


c. THIS 
PAGE 

u 


17. LIMITATION OF 

18. NUMBER 

ABSTRACT 

OF 


PAGES 

uu 

46 


19a. NAME OF RESPONSIBLE PERSON 

STI Help Desk (email:help@sti.nasa.gov) 


19b. TELEPHONE NUMBER (include area code) 

443-757-5802 


Standard Form 298 (Rev. 8-98) 
Prescribed by ANSI Std. Z39-18 



































